-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatpak: Create Autostart File Via Background Portal #681
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@Marukesu can you update this/resolve conflicts since there's now a single binary? |
Updated the PR, now this will show the dialog in two cases:
Also, the daemon is always started now, so that we can show notifications when the application is open, even if we don't have permission to run in background. |
Is there a reason to only use the background portal when running in Flatpak? Can we use it all the time? |
The GTK portal backend uses the sandboxed app id to name the autostart file, but for host apps it is empty, so they create an unnamed .desktop that is replaced by others application on host that calls the portal (see flatpak/xdg-desktop-portal#650). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm that after removing the existing Calendar installation with AppCenter and renaming the existing autostart file and installing a flatpak built from this PR and logging out and in again the following:
- No daemon was running initially
- Running the flatpak with
flatpak run
launched the program but did not start the daemon - Closing the window triggered a dialog requesting permission to run in background
- After giving permission the window closed but the daemon did not start
- After logging out and back in, the daemon did autostart.
- It was not possible to launch Calendar from the wingpanel indicator but launching from the dock and Applications Menu worked. (Is this an existing bug with flatpak/wingpanel?)
I would expect the daemon to start after giving it permission to do so and not have to log out and in.
I can't reproduce this here, starting the application should start the daemon, the only diference from master here is that starting the daemon is done before the
The last commit should fix that, for some reason, chaining up
Looking at the code in the indicator, it tries to launch |
@Marukesu wanna update this again and remove the flatpak check since the background portal can work with host apps now? :) |
81c0b81
to
14d3807
Compare
@danirabbit this should be good to review again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it would simplify things quite a bit to use LibPortal like we did for Mail?
bbaa582
to
4389670
Compare
Co-authored-by: Jeremy Wootten <jeremy@elementaryos.org>
Co-authored-by: Danielle Foré <danielle@elementary.io>
4389670
to
147228e
Compare
@@ -61,10 +63,17 @@ namespace Maya { | |||
} | |||
|
|||
protected override void activate () { | |||
new Calendar.TodayEventMonitor (); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be done in activate
? it looks like Mail does the equivalent in startup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, Calendar doesn't have a startup
method. This work since TodayEventMonitor is marked as a [SingleInstance]
class and the construct method will only be called one time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go 🚀 Thanks for working on this!
with this calendar will call the background portal to create the daemon autostart on the first launch when sandboxed.